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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 

The present document is part 4 of a multi-part deliverable covering Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services. Full details of the entire series can be found in 
part 1. 



Introduction 



The cable industry in Europe and across other Global regions has already deployed broadband cable television Hybrid 
Fibre Coax (HFC) data networks running the Cable Modem Protocol. The cable industry is in the rapid stages of 
deploying IP Voice and other time critical multimedia services over these broadband cable television networks. 

The cable industry has recognized the urgent need to develop ETSI Technical Specifications aimed at developing 
interoperable interface specifications and mechanisms for the delivery of end-to-end advanced real time IP multimedia 
time critical services over bi-directional broadband cable networks. 

IPCablecom is a set of protocols and associated element functional requirements developed to deliver Quality of 
Service (QoS) enhanced secure IP multimedia time critical communications services using packetized data transmission 
technology to a consumer's home over the broadband cable television Hybrid Fibre/Coaxial (HFC) data network 
running the Cable Modem protocol. IPCablecom utilizes a network superstructure that overlays the two-way data-ready 
cable television network. While the initial service offerings in the IPCablecom product line are anticipated to be Packet 
Voice, the long-term project vision encompasses packet video and a large family of other packet-based services. 

The cable industry is a global market and therefore the ETSI standards are developed to align with standards either 
already developed or under development in other regions. The ETSI Specifications are consistent with the 
CableLabs/PacketCable set of specifications as published by the SCTE. An agreement has been established between 
ETSI and SCTE in the US to ensure, where appropriate, that the release of PacketCable and IPCablecom set of 
specifications are aligned and to avoid unnecessary duplication. The set of IPCablecom ETSI specifications also refers 
to ITU-SG9 draft and published recommendations relating to IP Cable Communication. 

The whole set of multi-part ETSI deliverables to which the present document belongs specify a Cable Communication 
Service for the delivery of IP Multimedia Time Critical Services over a HFC Broadband Cable Network to the 
consumers' home cable telecom terminal. "IPCablecom" also refers to the ETSI working group program that shall 
define and develop these ETSI deliverables. 

Many cable television operators are upgrading their facilities to provide two way capability and using this capability to 
provide high speed IP data services per ITU-T Recommendations J. 83 and J.l 12 [1]. These operators now want to 
expand the capability of this delivery platform to include a variety of time critical services. The present document is one 
of a series of documents required to achieve this goal. It provides a network based call signalling protocol necessary to 
establish connections. 
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The present document is part 4 of the series of ETSI deliverables and specifies a profile of an application programming 
interface, Media Gateway Controller Interface (MGCI), and a corresponding protocol, Media Gateway Control Protocol 
(MGCP), for controlling Voice over IP (VoIP) embedded clients from external call control elements. The MGCP 
assumes a call control architecture where the call control "intelligence" is outside the media gateway and is handled by 
external call control elements. The profile, as described in the present document, will be referred to as the 
Network-based Call Signalling (NCS) Protocol. It is based on the Media Gateway Control Protocol (MGCP) 1.0 
RFC 3435, which is the result of a merging of the Simple Gateway Control Protocol, and the IP Device Control (IPDC) 
family of protocols, as well as additional ideas incorporated during the protocol development process. 
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Scope 



The present document is a multi-part deliverable belonging to IPCablecom. The present part (part 4) specifies a profile 
of an application programming interface, Media Gateway Controller Interface (MGCI), and a corresponding protocol, 
Media Gateway Control Protocol (MGCP), for controlling Voice over IP (VoIP) embedded clients from external call 
control elements. The MGCP is based on a call control architecture, where the call control "intelligence" resides outside 
the gateways and is handled by external call control elements. The profile, as described in the present document, is 
referred to as the Network Call Signalling (NCS) Protocol. 

Annex B of the present document specifies an expansion of the NCS protocol to emulate an Access Node of an ETSI 
compliant local exchange. This annex specifies the mapping of expansion of the NCS protocol to V5.2. 

Annex F of the present document specifies optional NCS components for the delivery of metering pulses. 

This multi-part deliverable specifies IPCablecom, a set of protocols and associated element functional requirements. 
These have been developed to deliver high Quality of Service (QoS), enhanced secure IP multimedia time critical 
communication services to a consumer's home over a cable television Hybrid Fibre/Coaxial (HFC) data network. 

NOTE 1 : IPCablecom defines a set of documents in the framework of a network superstructure that overlays the 

two-way data-ready cable television network, e.g. as specified within ES 201 488 [5] and ES 200 800 [3], 

While the initial service offerings in the IPCablecom product line are anticipated to be Packet Voice and Packet Video, 
the long-term project vision encompasses a large family of packet-based services. This may require in the future, not 
only careful maintenance control but also an extension of the present set of documents. 

NOTE 2: The present set of documents aims for global acceptance and applicability. It is therefore developed in 
alignment with standards either already existing or under development in other regions and in 
International Telecommunications Union (ITU). 

NOTE 3: There may also be relevant equivalent studies on-going in IETF or ITU specific to the needs of European 
IPCablecom. Where possible ETSI TC AT-D working group for IPCablecom should align annex B 
package annex or similar packages addressing the specific needs of European IPCablecom with work on 
going in IETF, Cablelabs, or the ITU. 
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[12] ETSI EN 300 347-1: "V interfaces at the digital Local Exchange (LE); V5.2 interface for the 

support of Access Network (AN); Part 1: V5.2 interface specification". 

[13] ETSI EN 300 166: "Transmission and Multiplexing (TM); Physical and electrical characteristics of 

hierarchical digital interfaces for equipment using the 2 048 kbit/s - based plesiochronous or 
synchronous digital hierarchies". 
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[15] ETSI TS 101 909-1 1: "Digital Broadband Cable Access to the Public Telecommunications 
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[18] ETSI ES 202 971 (see note): "Access and Terminals (AT); Public Switched Telephone Network 

(PSTN); Harmonized specification of physical and electrical characteristics of a 2-wire analogue 
interface for short line interface". 

NOTE: EN 300 001 (declared historical at present) and EG 201 188 (an initial study detailed and updated in other 
documents later) were taken as base for the present document but they were later updated in ES 201 970 
for the majority of the situations and in ES 202 971 for very short line interfaces, which is the most 
common case in IPCablecom systems. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Node (AN): layer two termination device that terminates the network end of the ITU-T Recommendation 
J. 112 [1] connection 

NOTE: It is technology specific. In ITU-T Recommendation J.l 12 [1], annex A, it is called the INA while in 
annex B it is the CMTS. 
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cable modem: layer two termination device that terminates the customer end of the J.l 12 connection 

embedded multimedia terminal adapter: physical and logical interface but it is physically integrated with the HFC 
Cable Modem functionality 

NOTE: The difference in MTA and E-MTA defines product design architectures and is not relevant to this annex 
therefore these terms and their abbreviations are used synonymously and inter-changeably throughout the 
present document. 

internet protocol access node: device in which the PacketCable Signalling Gateway (SG), Media Gateway (MG) and 
Media Gateway Controller (MGC) have been closely integrated 

NOTE: The MGC includes the subset of Call Management Server (CMS) (aka Call Agent) functionality required 
to support the inter-working between a PacketCable HFC access network and a SCN through a switched 
circuit, line-controlled interface such as V5. 

IPCablecom: ETSI working group project that includes an architecture and a series of specifications that enable the 
delivery of real time services (such as telephony) over the cable television networks using cable modems 

line treatment: signals that can be applied to or sensed from the subscriber's loop, such as loop open, loop closed, ring, 
reverse battery, etc. 

Multimedia Terminal Adapter (MTA): physical and logical interface between a line presence and the HFC Cable 
Modem (CM) 

V5: general descriptor used to reference the V5.1/V5.2 Signalling protocols at the digital Local Exchange 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AN Access Node 

BR BRief signal 

CA Call Agents 

CM Cable Modem 

CMS Call Management Server 

CMTS Cable Modem Termination System 

CPE Customer Premises Equipment 

DNS Domain Name System 

D-QoS Dynamic Quality of Service 

DTMF Dual Tone Multi Frequency 

E-MTA Embedded Multimedia Terminal Adapter 

HFC Hybrid Fibre Coax 

INA Interactive Network Adapter 

IP Internet Protocol 

IP AT Internet Protocol Access Terminal 

IPDC IP Device Control 

LE Local Exchange 

MFPB Multi Frequency Push Button 

MGCI Media Gateway Controller Interface 

MGCP Media Gateway Control Protocol 

MIB Management Information Base 

MTA Media Terminal Adaptor 

NCS Network Call Signalling 

OO On/Off 

PBX Private Branch eXchange 

PICS Protocol Implementation Compliance Statement 

POTS Plain Old Telephone Service 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RDT Remote Digital Terminal 

RQNT NoTificationReQuest 

RTCP Real Time Control Protocol 
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RTP 

RTSP 

SCN 

SDP 

SIP 

TDD 

TE 

TO 

VoIP 



Real-Time Protocol 
Real-Time Streaming Protocol 
Switched Circuit Network 
Session Description Protocol 
Session Initiation Protocol 
Telecomm Devices for the Deaf tones 
Terminal Equipment 
Time-Out 
Voice over IP 



Endorsement notice 

The elements of ITU-T Recommendation J. 162 apply, with the following modifications: 

All references to "European" are replaced with "ETSI". The use of European does not reflect any specific standards or 
requirements document while ETSI is recognized as a standards body on a world wide basis. 

ITU-T Recommendation J. 161 references replaced by TS 101 909-3 [19]. 

ITU-T Recommendation J. 162 references replaced by TS 101 909-4. 

ITU-T Recommendation J. 163 references replaced by TS 101 909-5. 

ITU-T Recommendation J.170 references replaced by TS 101 909-11 [15]. 



Global modifications to ITU-T Recommendation J. 162 

4 Void 

5 Overview 

The present document describes the NCS profile of an application programming interface (MGCI) and a corresponding 
protocol (MGCP) for controlling embedded clients from external call control elements. An embedded client is a 
network element that provides: 

• two or more traditional analogue access lines to a Voice over IP (VoIP) network; 

• one or more video lines to a VoIP network are for further study. 

Embedded clients may not be confined to residential use only. For example, they may be used in a business as well. 
Embedded clients are used for line-side access and, as such, are expected to have line-side equipment, e.g. analogue 
access lines for conventional telephones associated with them, as opposed to trunk gateways. 

The MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled 
by external call-control elements referred to as Call Agents. The MGCP assumes that these call-control elements, or 
Call Agents (CAs), will synchronize with each other to send coherent commands to the gateways under their control. 
The MGCP defined in the present document does not define a mechanism for synchronizing Call Agents, although 
future IPCablecom specifications may specify such mechanisms. 

The MGCP assumes a connection model where the basic constructs are endpoints and connections. A gateway contains 
a collection of endpoints, which are sources, or sinks, of data and could be physical or virtual. 

An example of a physical endpoint is an interface on a gateway that terminates an analogue POTS connection to a 
phone, key system, PBX, etc. A gateway that terminates residential POTS lines (to phones) is called a residential 
gateway, an embedded client or an MTA. Embedded clients may optionally support video as well. 

An example of a virtual endpoint is an audio source in an audio-content server. Creation of physical endpoints requires 
hardware installation, while creation of virtual endpoints can be accomplished by software. However, the NCS profile 
of MGCP only addresses physical endpoints. 
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Connections are point-to-point. A point-to-point connection is an association between two endpoints with the purpose 
of transmitting data between these endpoints. Once this association is established for both endpoints, data transfer 
between these endpoints can take place. The association is established by creating the connection as two halves; one on 
the origination endpoint, and one on the terminating endpoint. 

Call Agents instruct the gateways to create connections between endpoints and to detect certain events, e.g. off-hook, 
and generate certain signals, e.g. ringing. It is strictly up to the Call Agent to specify how and when connections are 
made, between which endpoints they are made, as well as what events and signals are to be detected and generated on 
the endpoints. The gateway, thereby, becomes a simple device, without any call state, that receives general instructions 
from the Call Agent without any need to know about or even understand the concept of calls, call states, features, or 
feature interactions. When new services are introduced, customer profiles changed, etc., the changes are transparent to 
the gateway. The Call Agents implement the changes and generate the appropriate new mix of instructions to the 
gateways for the changes made. Whenever the gateway reboots, it will come up in a clean state and simply carry out the 
Call Agent's instructions as they are received. 

5.1 Relation with H.323 standards 

The elements of ITU-T Recommendation J. 162 section 5.1 apply with the following modification: 

• the H.225.0 call signalling and H.245 media signalling is therefore routed to the Call Agent. 

5.2 Relation with IETF standards 

The elements of ITU-T Recommendation J. 162 section 5.2 apply with the following modification: 

• the Session Initiation Protocol (SIP), RFC 3261. 

5.3 Relation to RFC 3435 and ABNF Grammar 
The elements of ITU-T Recommendation J. 162 section 5.3 apply. 

6 Media Gateway Control Interface (MGCI) 

The elements of ITU-T Recommendation J. 162 section 6 through 6.1.3 apply. 

6.1 .4 Names of Call Agents and other entities 

The elements of ITU-T Recommendation J. 162 section 6.1.4 apply with the following note modification: 

In addition to the indirection provided by the use of domain names and the DNS, the concept of "notified entity" is 
central to reliability and fail-over in MGCP. The "notified entity" for an endpoint is the Call Agent currently controlling 
that endpoint. At any point in time, an endpoint has one, and only one, "notified entity" associated with it, and when the 
endpoint needs to send a command to the Call Agent, it MUST send the command to the current "notified entity" for 
which endpoint(s) the command pertains. Upon startup, the "notified entity" MUST be set to a provisioned value. Most 
commands sent by the Call Agent include the ability to explicitly name the "notified entity" through the use of a 
"NotifiedEntity" parameter. The "notified entity" MUST stay the same until either a new "NotifiedEntity" parameter is 
received or the endpoint reboots. If the "notified entity" for an endpoint is empty or has not been set explicitly 
(see note), the "notified entity" will then default to the source address of the last connection handling command or 
notification request received for the endpoint. Auditing will thus not change the "notified entity". 

NOTE: This could happen as a result of specifying an empty NotifiedEntity parameter. 

Clause 6.4 contains a more detailed description of reliability and fail-over. 

6.1.5 Digit maps 

The elements of ITU-T Recommendation J. 162 section 6.1.5 through 6.3 apply. 
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6.3.1 Notification Request 

The elements of ITU-T Recommendation J. 162 section 6.3.1 apply with the following modifications: 

Signals are divided into different types depending upon their behaviour: 

• Time-Out ( TO ) : Once applied, these signals last until they are either cancelled (by the occurrence of an 
event or by not being included in a subsequent [possibly empty] list of signals), or a signal-specific period of 
time has elapsed. A signal that times out will generate an "operation complete" event (please see annex A for 
further definition of this event). A TO signal could be "ringback" timing out after 180 s. If an event occurs 
prior to the 180 s, the signal will, by default, be stopped (see note 3). If the signal is not stopped, the signal will 
time out, stop and generate an "operation complete" event, about which the Call Agent may or may not have 
requested to be notified. If the Call Agent has asked for the "operation complete" event to be notified, the 
"operation complete" event sent to the Call Agent will include the name(s) of the signal(s) that timed out 
(see note 4). Signal(s) generated on a connection will include the name of that connection. Time-out signals 
have a default time-out value defined for them, which may be altered by the provisioning process. Also, the 
time-out period may be provided as a parameter to the signal. A value of zero indicates that the time-out period 
is infinite. A TO signal that fails after being started, but before having generated on "operation complete" 
event will generate an "operation failure" event, which will include the name(s) of the signal(s), that timed out 
(see note 5). 

NOTE 1: The "Keep signal(s) active" action may override this behaviour. 

NOTE 2: If parameters were passed to the signal, the parameters will not be reported. 

NOTE 3: These are merely examples from the example line package in 0. 

Persistent events are always detected on an endpoint. If a persistent event is not included in the list of RequestedE vents, 
and the event occurs, the event will be detected anyway, and processed like all other events, as if the persistent event 
had been requested with a Notify action (see note 7). Thus, informally, persistent events can be viewed as always being 
implicitly included in the list of RequestedE vents with an action to Notify, although no glare detection, etc., will be 
performed (see note 8). Persistent events are identified as such through their definition - see annex A. 

NOTE 4: Per ITU-T Recommendation J. 162 section 6.3.1 

NOTE 5: Thus the Requestldentifier will be the Requestldentifier of the current NotificationRequest. 

NOTE 6: Normally, if a request to look for, e.g. off -hook, is made, the request is only successful if the phone is not 
already off-hook. 

The signals being applied by the SignalRequests are synchronized with the collection of events specified or implied in 
the RequestedEvents parameter, except if overridden by the "Keep signal(s) active" action. For example, if the 
NotificationRequest mandated a "ringing" signal and the event request asked to look for an "off-hook" event, the 
ringing should, by default, stop as soon as the gateway detected an off-hook event. If "off-hook" was defined as a 
persistent event and the event request did not ask to look for an "off-hook" event, the ringing would stop anyway since 
off-hook would then be implied in the RequestedEvents parameter. The formal definition is that the generation of all 
"Time Out" signals MUST stop as soon as one of the requested events is detected, unless the "Keep signal(s) active" 
action is associated to the specified event. In the case of the action "accumulate according to digit map", the default 
behaviour would be to stop all active time-out signals when the first digit (see note 9) is accumulated - it is irrelevant to 
this synchronization if the accumulated digit results in a match, mismatch, or partial matching to the digit map. 

NOTE 7: Digit as defined in digit maps, i.e. including asterisk, timer, etc. 

The embedded ModifyConnection action allows the Call Agent to instruct the endpoint to change the connection mode 
of one or more connections immediately following the detection of the associated event. Each of connection mode 
changes work similarly to a corresponding ModifyConnection command (see note 10). When a list of connection mode 
changes is supplied, the connection mode changes MUST be applied one at a time in left-to-right order. When all the 
connection mode changes have finished, an "operation complete" event parameterized with the name of the completed 
action will be generated (see annex A for details). Should any of the connection mode changes fail, an "operation 
failure" event parameterized with the name of the failed action and connection mode change will be generated 
(see annex A for details) - the rest of the connection mode changes MUST NOT be attempted, and the previous 
successful connection mode changes in the list MUST remain effective. 

NOTE 8: Thus, if, e.g. D-QoS is used on the connection, the default D-QoS action will still be taken when the 
embedded ModifyConnection action is carried out. 
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6.3.2 Notifications 

The elements of ITU-T Recommendation J. 162 section 6.3.2 apply. 

6.3.3 CreateConnection 

The elements of ITU-T Recommendation J. 162 section 6.3.3 apply with the following modifications: 

• Packetization Period: The packetization period in milliseconds, as defined in the SDP standard (RFC 2327), 
MUST be specified and with exactly one value or a range of values. The value or range only pertains to media 
sent. A range is specified as two decimal numbers separated by a hyphen. Note that only valid packetization 
rates within a specified range may be used by the MTA. A list of permissible packetization periods is specified 
in TS 101909-3 [6]. 

The elements of ITU-T Recommendation J. 162 section 6.3.4 through 8 apply. 

Appendix VII Event Packages 

The elements of ITU-T Recommendation J. 162 Appendix VII apply with the following modifications: 

Each package defines a package name for the package and event codes and definitions for each of the events in the 
package. In the tables of events/signals for each package, there are five columns: 

Code: The package unique event code used for the event/signal. 

Description: A short description of the event/signal. 

Event: A check mark appears in this column if the event can be Requested by the Media Gateway 

Controller. Alternatively, one or more of the following symbols may appear: 

"P": indicating that the event is persistent; 

"S": indicating that the event is an event-state that may be audited; 

"C": indicating that the event/signal may be detected/applied on a connection. 

Signal: If nothing appears in this column for an event, then the event cannot be signalled on command by 

the Media Gateway Controller. Otherwise, the following symbols identify the type of event: 

"OO": On/Off signal. The signal is turned on until commanded by the Media Gateway Controller 
to turn it off, and vice versa; 

"TO": Timeout signal. The signal lasts for a given duration unless it is superseded by a new signal. 
Default time-out values are supplied. A value of zero indicates that the time-out period is infinite. 
The provisioning process may alter these default values; 

"BR": Brief signal. The event has a short, known duration. 

Additional info: Provides additional information about the event/signal, e.g. the default duration of TO signals. 

Unless otherwise stated, all of the events/signals are detected/applied on endpoints and audio generated by them is not 
forwarded on any connection the endpoint may have. Audio generated by events/signals that are detected/applied on a 
connection will however be forwarded on the associated connection irrespective of the connection mode. 

A. 1 Analogue Access Lines 

This clause defines an initial set of event packages for the various types of endpoints currently defined by IPCablecom 
for embedded clients. The following packages are defined for the embedded client endpoint-types listed: 



Endpoint-type 


Package 


Package name 


Default package 


Analogue Access Line 


Line 


L 


Yes 


FAX 


Fax Package 


FXR 


No 


VoIP RTCP-XR Metrics 
Package 


VoIP Metrics 


XRM 


No 


Expanded Analogue 
Access Line 


ETSI Expansion 


E 


No 
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The "E" line package is NOT A REPLACEMENT for the "L" package and in fact, one absolutely must support the 
"L" package to create a working service for the "E" package to operate. By declaring support for the "L" with "E" line 
package the CA, IP AT and CM/MTAs will clearly be identifying their ability to support the European Telephony 
Services and Features. 

A. 2 Analogue Access Lines 

The following packages are currently defined for Analogue Access Line endpoints. These packages apply to all 
endpoints: 

• Line Package name: L 

The following codes are used to identify events and signals for the "line" package for "analogue access lines": 



Code 


Description 


Event 


Signal 


Additional Info 


0-9,*,#,A, 
B,C,D 


MFPB (DTMF) tones 


V 


BR 




Bz 


Busy tone 


- 


TO 


Time-out = 30 s 


Cf 


Confirmation tone 


- 


BR 




ci(ti, nu, na) 


Caller Id 


- 


BR 


"ti" denotes time, "nu" denotes number, 
and "na" denotes name 


Dl 


Dial tone 


- 


TO 


Time-out = 16 s 


Ft 


Fax tone 


V 


- 




Hd 


Off-hook transition 


P, s 


- 




Hf 


Flash hook 


p 


- 




Hu 


On-hook transition 


P, s 


- 




L 


MFPB (DTMF) long 
duration 


V 


- 




Ld 


Long duration connection 


c 


- 




Ma 


Media start 


c 


- 




Mt 


Modem tones 


V 


- 




mwi 


Message waiting 
indicator 


- 


TO 


Time-out = 16 s 


Oc 


Operation complete 


V 


- 




Of 


Operation failure 


V 


- 




Osi 


Open interval 


- 


TO 


Default = 900 ms 


Ot 


Off-hook warning tone 


- 


TO 


Time-out = infinite 


rO, r1, r2, r3, 
r4, r5, r6 or 
r7 


Distinctive ringing (0..7) 




TO 


Time-out = 180 s 


Rg 


Ringing 


- 


TO 


Time-out = 180 s 


Ro 


Reorder tone 


- 


TO 


Time-out = 30 s 


Rs 


Ringsplash 


- 


BR 




rt 


Ring back tone 


- 


C, TO 


Time-out = 180 s 


SI 


Stutter dial tone 


- 


TO 


Time-out = 16 s 


T 


Timer 


V 


- 




TDD 


Telecomm Devices for 
the Deaf (TDD) tones 


V 


- 




vmwi 


Visual message waiting 
indicator 


- 


00 




wt1 , wt2, 
wt3, wt4 


Call waiting tones 


- 


TO 


Time-out = 12 s 


X 


MFPB (DTMF) tones 
wildcard 


V 


- 


Matches any of the digits "0-9" 



The definition of the individual events and signals are as follows: 

MFPB (DTMF) tones (0-9, *, #, A, B, C, D): Detection and generation of MFPB (DTMF) signals is described in 
ES 201 235 [4] series. It is considered an error to try and play MFPB (DTMF) tones on a phone that is off line (on 
hook) and an error should consequently be returned when such attempts are made (error code 402 - phone on hook). 
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Busy tone (bz): Station Busy is defined by the local administration, and MAY be re-defined via provisioning. 
See ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and play busy tone on a phone that is off line 
(on hook) and an error should consequently be returned when such attempts are made (error code 402 - phone off line 
(on hook)). 

Confirmation tone (cf): Confirmation Tone is defined by the local administration, and MAY be re-defined via 
provisioning. See ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and play confirmation tone on a 
phone that is off line (on hook) and an error should consequently be returned when such attempts are made (error code 
402 - phone off line (on hook)). 

Caller Id (ci(time, number, name)): See EN 300 659-1 [7] and ES 200 659-3 [10]. Each of the three fields is optional, 
however each of the commas will always be included: 

• The time parameter is coded as "MM/DD/HH/MM", where MM is a two-digit value for Month between 01 
and 12, DD is a two-digit value for Day between 1 and 31, and Hour and Minute are two-digit values coded 
according to military local time, e.g. 00 is midnight, 01 is 1 a.m., and 13 is 1 p.m. 

• The number parameter is coded as an ASCII character string of decimal digits that identify the calling line 
number. White spaces are permitted if the string is quoted, however they will be ignored. 

• The name parameter is coded as a string of ASCII characters that identify the calling line name. White spaces, 
commas, and parentheses are permitted if the string is quoted. 

A "P" in the number or name field is used to indicate a private number or name, and an "O" is used to indicate an 
unavailable number or name. The following example illustrates the use of the caller-id signal: 

S: ci (08/14/17/26, "33 4 92 94 42 00", ETSI) 

Dial-tone (dl): Dial Tone is defined by the local administration, and MAY be re-defined via provisioning. See ETSI 
ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and play dial-tone on a phone that is offline (on 
hook) and an error should consequently be returned when such attempts are made (error code 402 - phone off line (on 
hook)). 

Fax tone (ft): The fax tone event is generated whenever a fax call is detected by presence of V.21 fax preamble. 
REQ2872 The fax tone event SHOULD also be generated when the T.30 CNG tone is detected. See ITU-T 
Recommendations T.30 and V.21 (see bibliography). 

Off-hook transition (hd): See ES 201 970 [17] and ES 202 971 [18], Seize signal. 

Flash hook (hf): See ES 201 970 [17] and ES 202 971 [18], Register recall. 

On-hook transition (hu): See ES 201 970 [17] and ES 202 971 [18], Clear Signal. The timing for the on-hook signal is 
for flash response enabled. 

MFPB (DTMF) Long duration (L): The "MFPB (DTMF) Long duration" is observed when a MFPB (DTMF) signal 
is produced for a duration longer than two seconds. In this case, the gateway will detect two successive events: first, 
when the signal has been recognized, the MFPB (DTMF) signal, and then, 2 s later, the long duration signal. 

Long duration connection (Id): The "long duration connection" is detected when a connection has been established for 
more than a certain period of time. The default value is 1 hour, however this may be changed by the provisioning 
process. 

The event may be detected on a connection. When no connection is specified, the event applies to all connections for 
the endpoint, regardless of when the connections are created. 

Media start (ma): The media start event occurs on a connection when the first valid (see note 1) RTP media packet is 
received on the connection. This event can be used to synchronize a local signal, e.g. ringback, with the arrival of media 
from the other party. 

NOTE 1 : When authentication and integrity security services are used, an RTP packet is not considered valid until 
it has passed the security checks. 

The event may be detected on a connection. When no connection is specified, the event applies to all connections for 
the endpoint, regardless of when the connections are created. 
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Modem tones (mt): Modem tone (mt): The modem tone event is generated whenever a data call is detected by presence 
of V.25 answer tone (ANS) with or without phase reversal or V.8 modified answer tone (ANSam) with or without phase 
reversal. See ITU-T Recommendation V.25 [11] and V.8 (see bibliography). 

Message Waiting Indicator (mwi): Message Waiting indicator tone is defined by the local administration, and MAY 
be re-defined via provisioning. See ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and play 
message waiting indicator on a phone that is off line (on hook) and an error should consequently be returned when such 
attempts are made (error code 402 - phone off line (on hook)). 

Open Switch Interval (osi): See <voiceband data transmission interface - on-hook transmission without power 
ringing>: See also <call processing - abandoned call scenario> and also <K-Break (as specified 
in ES 201 970 [17]) - an end-of-call signal consisting of a reduction in the PSTN loop current to below 1 mA for a 
certain period is referred to as K-break. Two times are suggested for the break: 

a) a range of 90 ms to 130 ms; 

b) a range of 250 ms to 300 ms. This is preferred for new equipment to avoid overlapping with the register recall 
signalx 

Operation complete (oc): The operation complete event is generated when the gateway was asked to apply one or 
several signals of type TO on the endpoint, and one or more of those signals completed without being stopped by the 
detection of a requested event such as off-hook transition or dialled digit. The completion report may carry as a 
parameter the name of the signal that came to the end of its live time, as in: 

0: L/oc(L/dl) 

When the reported signal was applied on a connection, the parameter supplied will include the name of the connection 
as well, as in: 

0: L/oc (L/rt@0A3F58) 

When the operation complete event is requested, it cannot be parameterized with any event parameters. When the 
package name is omitted, the default package name is assumed. 

The operation complete event may additionally be generated as defined in the base protocol, e.g. when an embedded 
ModifyConnection command completes successfully, as in note 2: 

0: L/oc(B/C) 

NOTE 2: Note the use of "B" here as the prefix for the parameter reported. 

Operation failure (of): In general, the operation failure event may be generated when the endpoint was asked to apply 
one or several signals of type TO on the endpoint, and one or more of those signals failed prior to timing out. The 
completion report may carry as a parameter the name of the signal that failed, as in: 

0: L/of(L/rg) 

When the reported signal was applied on a connection, the parameter supplied will include the name of the connection 
as well, as in: 

0: L/of (L/rt@0A3F58) 

When the operation failure event is requested, event parameters can not be specified. When the package name is 
omitted, the default package name is assumed. 

The operation failure event may additionally be generated as specified in the base protocol, e.g. when an embedded 
ModifyConnection command fails, as in note 2: 

0: L/of (B/C(M(sendrecv(AB2354) ) ) ) 
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Off-hook warning tone (ot): Receiver Off Hook Tone (ROH Tone) or "howler" tone is defined by the local 
administration, and MAY be re-defined via provisioning. See ES 201 970 [17] and ES 202 971 [18]. It is considered an 
error to try and play off-hook warning tone on a phone that is off line (on hook) and an error should consequently be 
returned when such attempts are made (error code 402 - phone offline (on hook)). 

Distinctive ringing (rO, rl, r2, r3, r4, r5, r6 or r7): These power ring cadences are defined by the local administration 
and MAY be re-defined via provisioning. 

See ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and ring a phone that is on line (off hook) and 
an error should consequently be returned when such attempts are made (error code 401 - phone on line (off hook)). 

Ringing (rg): This power ring signal is defined by the local administration, and MAY be re-defined via provisioning. 
See ES 201 970 [17] and ES 202 971 [18]. The ringing signal may be parameterized with the signal parameter "rep" 
which specifies the maximum number of ringing cycles (repetitions) to apply. The following will apply the ringing 
signal for up to 6 ringing cycles: 

S : rg (rep=6) 

It is considered an error to try and ring a phone that is on line (off hook) and an error should consequently be returned 
when such attempts are made (error code 401 - phone on line (off hook)). 

Reorder tone (ro): Re-order tone is defined by the local administration, and MAY be re-defined via provisioning. See 
ETSI ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and play reorder tone on a phone that is off 
line (on hook) and an error should consequently be returned when such attempts are made (error code 402 - phone off 
line (on hook)). 

Ringsplash (rs): Ringsplash, also known as "Reminder ring" is a burst of power ringing that may be applied to the 
physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a Call 
Forwarding subfeature is active. This signal is defined by the local administration, and MAY be re-defined via 
provisioning. See ETSI ES 201 970 [17] and ES 202 971 [18]. It is considered an error to try and ring a phone that is on 
line (off hook) and an error should consequently be returned when such attempts are made (error code 401 - phone on 
line (off hook)). 

Ring back tone (rt): Audible Ring Tone is defined by the local administration, and MAY be re-defined via 
provisioning. See ETSI ES 201 970 [17] and ES 202 971 [18]. The ringback signal can be applied to both an endpoint 
and a connection. 

When the ringback signal is applied to an endpoint, it is considered an error to try and play ring back tones, if the 
endpoint is considered off line (on hook) and an error should consequently be returned when such attempts are made 
(error code 402 - phone off line (on hook)). When the ringback signal is applied to a connection, no such check is to be 
made. 

Stutter Dial tone (si): Stutter Dial Tone (also called Recall Dial Tone) is defined by the local administration, and MAY 
be re-defined via provisioning. See ETSI ES 201 970 [17] and ES 202 971 [18]. The stutter dial tone signal may be 
parameterized with the signal parameter "del" which will specify a delay in ms to apply between the confirmation tone 
and the dial tone (see note 3). The following will apply stutter dial tone with a delay of 1,5 s between the confirmation 
tone and the dial tone: 

S: sl(del=1500) 

NOTE 3: This feature is needed for, e.g. Speed Dialling. 

It is considered an error to try and play stutter dial tone on a phone that is off line (on hook) and an error should 
consequently be returned when such attempts are made (error code 402 - phone off line (on hook)). 

Tinier (t): As described in clause 6.15, timer T is a provisionable timer that can only be cancelled by MFPB (DTMF) 
input. When timer T is used with the "accumulate according to digit map" action, the timer is not started until the first 
digit is entered, and the timer is restarted after each new digit is entered until either a digit map match or mismatch 
occurs. In this case, timer T functions as an inter-digit timer and takes on one of two values, T or T crit . When at least 
one more digit is required for the digit string to match any of the patterns in the digit map, timer T takes on the value 
T , corresponding to partial dial timing. If a timer is all that is required to produce a match, timer T takes on the value 

T crit corresponding to critical timing. An example use is: 

S: dl 

R: [0-9T] (D) 
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When timer T is used without the "accumulate according to digit map" action, timer T takes on the value T crit , and the 
timer is started immediately and simply cancelled (but not restarted) as soon as a digit is entered. In this case, timer T 
can be used as an inter-digit timer when overlap sending is used, e.g.: 

R: [0-9] (N) , T(N) 

NOTE 4: That only one of the two forms can be used at a time, since a given event can only be specified once. 
The default value for T is 16 s and the default value for T crit is 4 s. The provisioning process may alter both of these. 

Telecomm Devices for the Deaf tones (TDD): The TDD event is generated whenever a TDD call is detected - see 
e.g. ITU-T recommendation V.18 (see bibliography). 

Visual Message Waiting Indicator (vmwi): The transmission of the VMWI messages will conform to the 
requirements in EN 300 659-1 [7], clause 6.2 Data transmission not associated with ringing and ES 200 659-3 [10], 
clause 5.2.2 Message Waiting Indicator message. VMWI messages will only be sent from the embedded client to the 
attached equipment when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message 
will be delayed until the line goes back to the idle state. The Call Agent should periodically refresh the CPE's visual 
indicator. 

Call Waiting tonel (wtl, .., wt4): Call Waiting tones are defined by the local administration, and MAY be re-defined 
via provisioning. See ES 201 970 [17] and ES 202 971 [18], It is considered an error to try and apply call waiting tones 
on a phone that is off line (on hook) and an error should consequently be returned when such attempts are made (error 
code 402 - phone off line (on hook)). 

MFPB (DTMF) tones wildcard (X) : 

The MFPB (DTMF) tones wildcard matches any MFPB (DTMF) digit between and 9. 

The elements of ITU-T Recommendation J. 162 annex A. 3 FAX Package apply. 

The elements of ITU-T Recommendation J. 162 annex A.4 VoIP Metrics Package apply. 

Appendix VIII Expansion of the NCS protocol "L" Line Package 

VI 11.1 Overview 

The elements of ITU-T Recommendation J. 162 Appendix VIII apply with the following modifications: 

This appendix specifies an expansion of the NCS protocol, described in the body of the present document, to emulate an 
Access Network to an ETSI compliant Local Exchange (LE) that forms a part of a SCN. This annex specifies the 
mapping between the NCS protocol and a subset of the V5.2 protocol, see EN 300 324-1 [2] applicable for the support 
of SCN services to analogue telephones. 

NOTE 1 : This annex has been produced in response to requests of current European Cable Operators to provide 

telephony services over their HFC cable plants while using existing V5 Switch capacity for SCN access, 
as described by ECCA EuroPacketCable working group requirements document 
(EPC-RequDoc-V 1 0-22050 1 ) . 

This appendix applies to a subset of the V5 signalling protocol that relates to services provided by a 2-wire (a-b 
terminals), loop start, analogue POTS line. 

NOTE 2: Support for additional line types is for further study. 

NOTE 3: It should be recognized that while the proposed protocol enables the support of the suite of V5 SCN 

POTS services that due to evolving market requirements some of these services may no longer be desired 
or may have been discontinued within some administration boundaries. Therefore it is recommended that 
product compliance with the protocol in support of these services be based on manufacturers' declaration, 
similar to practices followed with V5 PICS declarations and not on "mandated" Services compliance. In 
cases where a product may not support a specific service, protocol compliance should be interpreted as 
being able to accept the protocol interface and mitigate mismatches in service requests to product 
capabilities. In this way product complexity and cost can be optimized per market requirements and 
administration needs while maintaining protocol inter-operability. 
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NOTE 4: The description of the signals defined for automatic metering given by this annex and that described for a 
standalone metering package in annex F are the same intentionally, and should remain aligned. The 
equivalence of the meter pulse signals as described in this annex and that described in annex F is directly 
mapped; E/ps(lt=em) maps directly to am/em and E/ps(mpb) maps directly to am/mpb respectively. These 
signals accept the same parameter usage in both packages. Annex F provides information on the package 
for standalone automatic metering and if it is applied then the package shall be implemented. 

NOTE 5: In the present document, ITU-T Recommendation G.71 1 [9] only is assumed. All other codecs must be 
considered as a future study. 

NOTE 6: ISDN/BRI lines are for further study. 

NOTE 7: It should be recognized by the alignment with the body of the present document that the definition in this 
annex provide expansions to the "L" package and can enable VoIP architecture external call control 
elements to control and manage call activity in a manner to emulate the V5 services and features in a 
VoIP architecture. 

VIII.2 I PAT architecture 

The elements of ITU-T Recommendation J. 162 section VIII.2 IP AT architecture apply. 



VIII.3 



Electrical and physical interface requirements 



This appendix references the EN 300 324-1 [2] defined system architecture consisting of a Local Exchange (LE) and an 
Access Network (AN) connected via a V5 interface. The use of this annex in a pure VoIP architecture will emulate the 
reference architecture performance and services. 

The V5 interface may have between one and sixteen 2 048 kbit/s interface as defined in EN 300 347-1 [12], 
EN 300 166 [13] and EN 300 167 [14]. 

The electrical and physical characteristics of the interface shall conform to EN 300 166 [13], 2 048 kbit/s case. 

Two interface presentation alternatives are defined in EN 300 166 [13], the balanced interface pair type and the coaxial 
type. According to the two alternatives of interface applications shown in figure VIII. 2/J. 162, it is left to the network 
operator to request the interface presentation required. 





Interface VS 




Access 
Network 








LE 


T 


TV 





Access 
Network 








Transparent digital link 








LE 














la 




lb 



NOTE: la = interface point at the Access Network side, 
lb = interface point at the LE side. 

Figure VIII.2/J.1 62 - V5 interface presentation alternatives 
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To expand the NCS signalling protocol definitions in this annex the AN is expanded to define a PacketCable network 
consisting of an Internet Protocol Access Terminal (IP AT), a Cable Modem Terminal System (CMTS), a Cable Modem 
(CM) and a Multimedia Terminal Adapter (MTA) or an Embedded Multimedia Terminal Adapter (E-MTA). 



Access Network (AN) 







NOTE: Ic = interface point at the user premises side. 

Figure VIII.3/J.162 - Access network 

This Access Network is the synonymous to an access network utilizing a Remote Digital Terminal (RDT) in the 
traditional Circuit Switch architecture. 

The electrical and logical definitions of the IP Network and the HFC Network are the subject of other standards 

activities. 

This appendix assumes that these networks simply provide the transparent digital link as described in EN 300 324-1 [2]. 
This allows this annex to focus on the method of providing the signalling necessary between the V5 LE to the premises 
interface point as defined in EN 300 324-1 [2] in support of the desired services at the user premises termination point. 

For cadence ringing requests, the annex defines an expanded range of ring cadences using a similar syntax as the NCS 
"L" line package in annex A ringing cadence signals. 

For pulsed and steady state signals, the annex allows an external call element to emulate or a PacketCable IP AT to 
translate a V5 protocol message received from the V5 switch to a corresponding signal request from the IP AT or call 
element to the E-MTA specifying the desire signal to be applied to the premises termination point (line treatment; pulse 
duration, pulse period and number of repetitions, etc.). The annex also includes a means for the IP AT to support the V5 
switch requests for acknowledgements. 

VIM. 4 NCS package for V5 SCN protocol messages 

The elements of ITU-T Recommendation J. 162 appendix VIII. 4 apply with the following modifications: 

This clause describes additional IPCablecom signal requests and an event request that creates the ETSI "E" Line 
Package which is an extension to the "L" line package described in annex A. 

These signal requests and event requests map the corresponding information elements contained in a V5 SCN protocol 
Message Type, in a binary format, to the NCS format. 

NOTE: Default values given in this annex are for the purpose of providing equipment vendors with values for 
initial product shipment. 

Provisions should be provided to allow these values to be overwritten as part of unit configuration or 
provisioning with alternate values per local administration requirements. 

The following package Expansion is currently defined for Expanded Analogue Access Line endpoints. These packages 
apply to all endpoints: 

• Line. Package name: E 

The following codes are used to identify events and signals for the "E" package for "expanded analogue access lines". 
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Code 


Description 


Event 


Signal 


Additional Info 


cr(x) 


Ringing Cadence 
(x = 0to 127) 


- 


TO 




Ta 


Alerting Signal Tone 


- 


TO 




Td 


Special Dial Tone 


- 


TO 




Ti 


Special Info Tone 


- 


TO 




Tr 


Release Tone 


- 


TO 




Tc 


Congestion Tone 


- 


TO 




Ps1 


Programmable Signal 1 


- 


TO 




Ps2 


Programmable Signal 2 


- 


TO 




Ps3 


Programmable Signal 3 


- 


TO 




Ps4 


Programmable Signal 4 


- 


TO 





The definitions of the individual events and signals are as follows: 

Ring Cadence (cr(0), cr(l) through cr(127): These power ring cadences are defined by the local administration and 
MAY be re-defined via provisioning. 

See TR 101 183 for some national cadences. It is considered an error to try and ring a phone that is on line (off hook) 
and an error should consequently be returned when such attempts are made (error code 401 - phone on line (off hook)). 

Alerting Signal Tone (ta): Alerting Signal tones are defined by the local administration, and MAY be re-defined via 
provisioning. See ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

Special Dial Tone (td): Special Dial tones are defined by the local administration, and MAY be re-defined via 
provisioning. See ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

Special Info Tone (ti): Special Info tones are defined by the local administration, and MAY be re-defined via 
provisioning. See ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

Release Tone (tr): Release tones are defined by the local administration, and MAY be re-defined via provisioning. See 
ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

Congestion Tone (tc): Congestion tones are defined by the local administration, and MAY be re-defined via 
provisioning. See ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

Programmable Signal (psl, ps2, ps3, ps4): Programmable Signal tones are defined by the local administration, and 
MAY be re-defined via provisioning. See ITU-T Supplement 2 for E.180, Tones Used in National Networks. 

VIM. 4.1 Cadence-ringing request 

The elements of ITU-T Recommendation J. 162 section VIII.4.1 apply. 

VIM. 4.1 .1 Cadence ringing defaults and ranges 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 1.1 apply. 

VIM. 4. 2 Pulsed signal request 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2 apply. 

VIM. 4. 2.1 Line treatment encoding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.1 apply. 
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VIM. 4. 2. 2 Line treatment defaults and ranges 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.2 apply with the following modification: 

Table VIII.3/J.162 - Line treatment defaults and ranges 



It 

Code 


Description 


Frequency 
(tolerance) 


Amplitude 
(min-max, steps) 


pd 

(min-max, 

steps) 


pr 

(min-max, 
steps) 


rep 

(min-max, 

steps) 


Ir 


Initial Ring 


25 Hz 

(±1 Hz) 


Full 


200 
(0 to 5 000, 50) 


200 
(0 to 5 000, 50) 


1 
(1 to 5, 1) 


Lc 


Pulsed loop closed 


null 


null 


200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


Lo 


Pulsed loop open 


null 


null 


200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


Em 


(Enable) metering 
pulse generation 


16 KHz 

(±1%) 


-13,5 dBml 
(-25dBto+15,2dB) 


150 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


null 


Mpb 


Metering pulse 
burst generation 


16 KHz 

(±1 %) 


-13,5 dBml 
(-25dBto+15,2dB) 


150 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 1 0) 


1 
(1 to 4095, 1) 


Nb 


Pulsed no battery 


Null 





200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


Np 


Pulsed normal 
polarity 


Null 


1 


200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


Rb 


Pulsed reduced 
battery 


Null 


1 


200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


Rp 


Pulsed reversed 
polarity 


Null 





200 
(0 to 5 000, 10) 


1 000 
(0 to 5 000, 10) 


1 
(1 to 50, 1) 


NOTE 1 : Meter Pulse Amplitude is specified in dBm across a-b terminals terminated in the reference termination 

impedance per national norms. Refer to ES 201 970 [17]. 
NOTE 2: Frequency may be provisioned for 12 KHz (±1 %). 



Vlll.4.2.3 Requested events 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.3 apply. 

VIM. 4. 2. 4 Pulse encoding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.4 apply. 

VIM. 4. 2. 4.1 Pulse duration encoding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.4. 1 apply. 

VIM. 4. 2. 4. 2 Pulse period encoding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.4. 2 apply. 

VIM. 4. 2. 5 Pulse completion event coding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.4. 3 apply. 

VIM. 4. 2. 6 Metering pulse report coding 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.6 apply. 

VIM. 4. 2. 7 V5 suppression indicator 

The elements of ITU-T Recommendation J. 162 section VIII.4.2.7 apply. 
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VIM. 4. 2. 7.1 No suppression 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2. 7.1 apply. 

VIM. 4. 2. 7.2 Suppression by pre-defined V5 signal message 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2. 7. 2 apply. 

VIM. 4. 2. 7.3 Suppression by pre-defined line signal from TE 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2. 7. 3 apply. 

VIM. 4. 2. 7.4 Suppression by pre-defined V5 SIGNAL message from LE or pre-defined line signal 

from TE 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2. 7. 4 apply. 

VIM. 4. 2. 8 Repetition indicator 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 2. 8 apply. 

VIM. 4. 3 Pulse repetition encoding 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 3 apply. 

VIM. 4. 4 Parameter usage 

The elements of ITU-T Recommendation J. 162 section VIII. 4.4 .4 apply. 

VIM. 4. 5 Pulsed signal cancellation 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 5 apply. 

VIM. 4. 6 Pulsed completion event 

The elements of ITU-T Recommendation J. 162 section VIII.4.6 apply. 

VIM. 4. 7 Pulsed signal failure event 

The elements of ITU-T Recommendation J. 162 section VIII.4.7 apply. 

VIM. 4. 8 Steady-signal request 

The elements of ITU-T Recommendation J. 162 section VIII. 4. 8 apply. 

VIM. 4. 8.1 Line treatment encoding 

The elements of ITU-T Recommendation J. 162 section VIII.4.8.1 apply. 

VIM. 4. 8. 2 Line treatment provisioning 

The elements of ITU-T Recommendation J. 162 section VIII.4.8.2 apply. 

VIM. 4. 9 Metering pulse generation 

The elements of ITU-T Recommendation J. 162 section VIII.4.9 apply with the following modification: 

On receiving an "enable metering pulse generation" ps(lt=em(+)) signal request the MTA shall apply the first metering 
pulse to the termination immediately, and then apply subsequent metering pulses at intervals as specified by the value of 
the pulse repetition interval parameter pr, if supplied in the signal request, or the provisioned value. 
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The MTA shall continue to generate metering pulses until it receives a "disable metering pulse generation" 
ps(lt=em(-)) signal request, or an empty signal request list. 

A metering pulse burst signal ps(lt=mpb) request may be included in a signal request that also enables metering pulse 
generation, for example, to apply an initial charge to a call. When this occurs, the MTA shall apply the metering pulse 
burst to the endpoint completely, and then start generating normal metering pulses. 

Because the metering pulse burst signal is a brief signal type, all pulses specified for the request (rep=n) are applied, 
even if the subscriber goes on-hook during the burst. This is to complete the billing reporting to the subscriber device. 
Should the subscriber shall go back off-hook prior to the metering completion, the original meter pulse request shall be 
completed and any new metering pulse sequence should then be applied. 

A metering pulse burst signal request may occur during a call in progress, for example to take account of a chargeable 
subscriber action. When this occurs, the MTA shall suspend normal metering pulse generation, and apply the metering 
pulse burst signal request. The MTA then shall resume normal metering pulse generation without requiring a new 
"enable metering pulse generation" request from the IP AT. The IP AT or external call element must account for any 
normal metering pulses missed during the burst by including the missed pulses in the burst count. 

The IP AT or external call element may optionally include a report pulse count (rpc) parameter with the enabling 
metering pulse generation (em) signal request. When this parameter is non-zero (rpc=n, where n=l to x), the MTA 
generates meter pulse reports, in the form of notifications, each time its pulse count reaches the rpc value. Generation of 
the event notification resets an rpc counter so that a report will be generated each time the rpc "n" value is reached. This 
count does not include any metering pulses generated by metering pulse burst (mpb) signal requests. 

VIM. 5 Provisioning configurations 

The elements of ITU-T Recommendation J. 162 section VIII. 5 apply. 

VIM. 6 ETSI Expansion line package support 

The elements of ITU-T Recommendation J. 162 section VIII. 6 apply with the following modifications: 

The important line for packages is the "v:L;E" which indicates support for the NCS Line Package (L) and for the 
Expansion line package (E). 

VIM. 7 Call flow examples 

The elements of ITU-T Recommendation J. 162 section VIII. 7 apply with the following modifications: 

The following call flow examples assume a V5-IPAT architecture. In a full VoIP architecture the V5-IPAT call flows 
may be provided by an external call element (Call Agent). 

VIM. 7. 2.1 Pulse signal request for one loop open pulse 

The elements of ITU-T Recommendation J. 162 section VIII. 7. 2. 2 apply with the following modifications: 



Access 
Line 



MTA 



I PAT 



LE 



4: open loop 


2: RQNT(S:ps(lt=lo,pd=200,rep=1 )) 


1 : Loop Open 




3: 200 OK 







Figure VIII.4/J.162 - Pulsed signal request 



ETSI 



24 



ETSI TS 101 909-4 V1.5.2 (2006-08) 



VIM. 7. 2. 5 Pulsed signal - Meter pulse with pulse acknowledgement 

The elements of ITU-T Recommendation J. 162 section VIII. 7. 2. 5 apply with the following modifications: 



Access 
Line 



MTA 



I PAT 



LE 



4: meter pulse 


2: RQNT(S:ps(lt=em(+)),R:pc) 


1 : Meter Pulse Start 


6: Ack 


3: 200 OK 


5: NTFY(pc) 




7: 200 OK 


8: Meter Pulse Stop 


9: RQNT(S:ps(lt=em(-))) 


• 
• 
• 






10: 200 OK 





Figure VIII.4/J.162 - Pulsed signal request 

VIM. 7. 3 Fixed meter pulse application, completed 

The elements of ITU-T Recommendation J. 162 section VIII. 7. 3 apply with the following modifications: 



Access 
Line 



MTA 



LE 



2: 

4: meter pulse 


RQI\rr(S:ps(lt=mpb,pd=150,pr=2000,rep=25),R:cc) 


1: Meter Pulse Start 


7: Ack 


3: 200 OK 


5: NTFY(oc(E/ps(mpb))) 






• 
• 
• 




6: 200 OK 







Figure VIII.9/J.162 - Fixed meter pulse application, completed 
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Annex B Dynamic Quality of Service 

The elements of ITU-T Recommendation J. 162 Annex B Dynamic Quality of Service apply. 

Appendix IV Connection mode 

The elements of ITU-T Recommendation J. 162 Appendix IV Connection mode apply. 

Appendix V Compatibility information 

The elements of ITU-T Recommendation J. 162 Appendix V Compatibility information apply. 

Appendix IX Metering support for IPCablecom 

The elements of ITU-T Recommendation J. 162 appendix IX Metering support for IPCablecom apply. 
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